The Internet Protocol (IP) has become the dominant transport protocol in both wireline and wireless networks, which leads to the convergence of telecommunication and data networks. In many services and applications, e.g., Voice over IP, interactive games, instant messaging, etc, the payload of the IP packets is almost of the same size or even smaller than the header. In addition to IP transport protocol, other protocols, such as RTP (real-time protocol), UDP (user datagram protocol) are added to the original information bits for effective transport in a packet data network. Over the end-to-end connection, comprised of multiple hops, these protocol headers are extremely important but over just one link (hop-to-hop) these headers can be compressed (and must be decompressed at the other end of the link). It is possible to compress those headers, providing in many cases more than 90% savings, and thus save the bandwidth and use the expensive resource efficiently. IP header compression also provides other important benefits, such as reduction in packet loss and improved interactive response time.
FIG. 1 shows a general architecture of a wireless communication network. An access terminal (AT) communicates with the base station (BTS) over the air interface. Multiple base stations communicate with a radio network controller (RNC), which provides signaling and traffic processing for each wireless data session. AT, BTS, RNC and the interfaces between the components consist of the radio access network (RAN). The packet data service node (PDSN) resides in the core network and is allocated by the service network where an AT initiates a service session. The AT establishes an active connection for a data session with the networks. Packets are transmitted and received from the AT to BTS, RNC, PDSN and the core network.
IP header compression is applied to packets sent over the communication link in the RAN to conserve scarce bandwidth and improve transport efficiency. There are two options where the compressor and decompressor can reside: between AT and RNC, or between AT and PDSN. When the AT establishes a connection with the network, for example, a VoIP call, the application layer packet will be carried over the RTP/UDP/IP protocol stacks. The RTP/UDP/IP protocol headers will be compressed by the compressor using, e.g., the Robust Header Compression (ROHC) algorithm. The compressed packet will be sent over to RNC and PDSN. The decompressor at either RNC or PDSN will decompress the ROHC header and re-establish the original RTP/UDP/IP headers and add it to the application layer packet to the core network. On the downlink direction, PDSN and RNC receive the IP packets from the core network. The compressor at either PDSN or RNC will compress the RTP/UDP/IP headers generating the ROHC header and send it over to the AT. The decompressor at the AT will regenerate the original RTP/UDP/IP headers and pass them to the application layer.
Various header compression algorithms have been proposed and implemented in wireline and wireless networks. The basic concepts behind the header compression algorithms are to exploit the redundancy in the headers from the same packet stream. Some static fields in the header that do not change from packet to packet are only sent once in the beginning. For the changing fields in the headers, delta compression is used to send only the difference in the value of the fields to minimize the number of bits sent. The ROHC compression algorithm uses window based least significant bits encoding for the compression of the dynamic fields in the protocol headers. It also incorporates a feedback mechanism. ROHC is robust on wireless links with high error rate and long round trip time. It is very efficient and robust which is suitable for wireless networks where the radio resource is expensive.
The general procedures comprising the operation of header compression are described as follows:                1. The compressor and decompressor first need to establish the context information to be used for compression and decompression.        2. After the context establishment, the compressor starts to send packets with compressed headers.        3. There are states defined for both compressor and decompressor. The compressor starts from the lowest compression state and transits gradually to higher compression states. In higher compression states, the compressor can compress the header more efficiently, i.e., to a smaller size of the compressed packet than in the lower compression states.        4. The decompressor starts in its lowest compression state and transits gradually to the higher states. Once a packet is decompressed correctly, the decompressor can transit to the highest state, i.e., “Full Context” state, and decompress packets based on the established context information.        5. Ideally, if there is no packet loss or misordering of packets along the channel, the compressor will reach the optimum compression state which produces the most efficient compressed header and the decompressor can decompress the packets successfully.        6. Decompression failures may happen when there is a large amount of packet loss or large degree of misordering of packets. When repeated failures happen, the decompressor usually will send a feedback packet to the sender asking the compressor to resynchronize the compression status by sending the full header packet. Before receiving the full header information, the decompressor will discard the received packets with compressed header even if the packets are uncorrupted. During the resynchronization between the compressor and decompressor, additional packet losses will occur and thus degrade the performance and quality of the call. Therefore, it is important to quickly recover the decompression failure and minimize the overall packet loss.        
Most of the header compression algorithms were designed based on the assumption that the channel between the compressor and decompressor will be required to maintain packet ordering for each compressed flow. The motivation behind this assumption was that the primary candidate channels considered did guarantee in-order delivery of header-compressed packets. With this assumption, it is possible to improve the compression efficiency and the tolerance to packet loss, objectives that were near the top of the requirements list for algorithm design.
However, some channels of at least some networks do not guarantee in-order delivery all the time. Some channels may choose not to do packet in-order delivery to reduce the re-sequencing delay for delay-sensitive applications.
Thus, there is a need to enhance header-compression algorithms to accommodate channels that may reorder the header-compressed packets. It would be advantageous for header-compression algorithms to be made robust against anticipated levels of such reordering.